The present invention is generally directed to a mechanism that facilitates customizing multiple computing devices. The present invention may be particularly beneficial when the computing devices are thin client with an operating system that employs a write filter to prevent modifications to the operating system image but may equally be employed when the thin clients or other computing devices do not include a write filter.
Thin client operating systems oftentimes provide functionality that can prevent the content of a storage medium from being changed permanently. In a typical example, it may be desirable to prevent the operating system image, which may be stored on a particular disk partition or on flash media, from being changed. To accomplish this, the thin client operating systems may provide a write filter that redirects I/O requests that would otherwise modify the contents of a protected volume to a temporary cache. These modifications can be maintained temporarily to provide the appearance that the contents is actually be updated on the protected volume. However, once the system reboots, the modifications will be discarded to return the system to its original state.
In the Windows Embedded operating system, there are two types of write filters that are available to provide this functionality: a file-based write filter which operates at the file level and a block-based write filter (or enhanced write filter) that operates at the block level. These write filters redirect all writes that target a protected volume to a RAM or disk cache called an overlay.
FIG. 1 illustrates how a file-based write filter 110 can be employed to prevent the contents of a protected volume on disk 100 from being modified. Disk 100 is intended to generally represent any type of physical storage medium (or volume). In accordance with the Windows architecture, a driver stack consisting of file system driver 111, volume manager 112, and disk driver 113 sit atop disk 100, and I/O manager 120 manages the flow of I/O requests through the driver stack. An application (not shown) can employ file/directory management APIs 160 to invoke a service of system services 130 (e.g., by calling ReadFile, WriteFile, CreateFile, etc. on a particular file) which will result in I/O manager 120 creating an IRP for the request. This IRP will then be passed down through the driver stack.
As depicted in FIG. 1, file-based write filter 110 is positioned at the top of the driver stack and will therefore be able to process an IRP prior to the IRP being passed down to the lower level drivers. It is noted that, if the block-based write filter were instead employed, it would be positioned below file system driver 111 so that it may operate at the block level. File-based write filter 110 (as well as the block-based write filter) can be configured to detect writes targeting a protected volume and redirect them to overlay 140 rather than allowing them to be passed down the driver stack. As a result, the write will actually occur in overlay 140 rather than to disk 100. File-based write filter 110 can be further configured to detect reads that target content that was previously redirected to overlay 140 and redirect these reads to overlay 140. In this way, even though it will appear to the application that the content of disk 100 is being updated, the updates are actually being temporarily maintained in overlay 140. The contents of overlay 140 can be maintained until the operating system is restarted or until an explicit command is received to discard the contents of the overlay.
When an organization employs thin clients, it is typically desired to maintain a consistent operating system image on many thin clients. For example, the same image may be deployed to every thin client used by users in a particular group or by all users in the organization. In such cases, it can be very burdensome to perform an update, particularly when the thin clients employ a write filter. For example, to make an update permanent on a thin client with a write filter, it will be necessary to reboot to either disable the entire write filter or to add an exclusion that would permit the particular artifact on the protected volume to be updated. After the update is performed, it will then be necessary to reboot a second time to either enable the write filter or remove the exclusion. For this reason, users cannot use a thin client during the update process, at least not efficiently or securely. Also, in an organization with potentially thousands of thin clients that need to be updated, the process can be tedious and lengthy even if a management solution is employed.